Send the patch, after verifying that it follows the above rules, to [email protected]. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.

Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). Option 3 is especially useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s have changed in the meantime).

Note that for Option 3, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very clearly documented and justified in the patch description.

The upstream commit ID must be specified with a separate line above the commit text, like this:

Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following format in the sign-off area:

The tag sequence has the meaning of:

Also, some patches may have kernel version prerequisites. This can be specified in the following format in the sign-off area:

The tag has the meaning of:

For each “-stable” tree starting with the specified version.

Following the submission:

The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer’s schedules.

If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer.